Chip 1996 April

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1996 April / CHIP 1996 aprilis (CD06).zip / CHIP_CD06.ISO / hypertxt.arj / 9403 / GIGANTO1.CD < prev next >

Wrap

Text File | 1994-11-26 | 30KB | 467 lines

@VStreamerek@N @VGIGAntománia -- I.@N Ha valaki elszánt shareware-, hanganyag- és képgyûjtô, pár hónap alatt sokszáz Mbyte anyagot szedhet össze a PC-s világban. Egy-két év, és megvan az elsô ""giga". Hol lehet ezt tárolni?! Merevlemezen? Ez lenne az ideális, csak nagyon sokba kerül, és ha nincs hova lementeni, hamarosan retteghetünk, mikor csap be egy villám hardverhiba vagy vírus képében... CD-ROM? Bár utólag nem módosítható a rögzített anyag, de viszonylag olcsó megoldás, és elég gyors. Åm lementetlen vinyónkat továbbra is fenyegeti a halál... Valaha elég volt néhány doboz floppy, és egy-két óra alatt teljes mentést (backup) készíthettünk merevlemezünkrôl. A vinyók kapacitásának növekedtével (amit az egyre kövérebb szoftverek meg is követeltek), a második vincsi beszerzésekor a floppys mentés egyre nehezebbé vált. Felhasználónként változó, hogy mikor, de elôbb-utóbb mindenki felhagy a floppys mentésekkel, és attól fogva az égiektôl függ, hogy mikor vész vagy nem vész kárba sokhónapi munkája, amit gépi munkakörnyezetének kiépítésébe, finomításába fektetett. A programokat, legfontosabb adatokat általában megôrzik floppykon, de ezekbôl újraépíteni a gépi környezetet rengeteg munkába kerül, s mindenképp elvész egy csomó elmentetlen holmi. A különféle programok és adatok floppys archiválása pedig -- bár elfogadható megoldás, hiszen itt csak egyszer kell felírni floppyra az anyagokat -- csak azok számára követhetô út, akik nagyon gondosan, áttekintôen végzik az archiválást (például én sajnos nem ilyen vagyok), különben a lemezhalmaz hamar kaotikussá válik. Az olcsó, viszonylag gyors mentések és archiválások eszközei hagyományosan a szalagmeghajtók. Az elsô Gbyte tárolókapacitás ma már (áfával együtt) 40 ezer Ft alatt elérhetô velük. És ez a kapacitás írható is, nem úgy, mint a CD-ROM-okon! Az elavult programok, anyagok kiselejtezhetôk készletünkbôl (CD-ROM esetén nem), s a streamerek megoldják backup-gondjainkat is. Mi akkor a gond? òdzkodunk a streamerektôl. Lassúak, nehézkesek, könnyen elvésznek rajtuk az adatok -- legalábbis ilyen tapasztalatokat szereztünk velük eddig. S nemrégiben még meglehetôsen drágák is voltak. '92 októberében (96. oldal) Krizsán György kollégám tesztelt nálunk három streamert. Nem tetszettek neki (nekünk sem). A három Summit gyártmány közül az egyetlen gyors streamer, az SE 305 sajnos csak egy mentésre volt hajlandó szalagonként (legalábbis a melléadott szoftverrel). Az archiválás és mentés kettôs követelményének kedvezô áruk ellenére egyik Summit streamer sem felelt meg. @VArchiválás és mentés@N A streamereket szerintem e két, jól meghatározott célra -- archiválásra és mentésre -- lehet jól használni. Miért? A háttértárak közül a merevlemezek a ""legjobbak". Gyorsak, írhatók és olvashatók, csak éppen még ma sem (eléggé) olcsók. A sebesség, írhatóság és olvashatóság összefoglaló jellemzôk, érdemes árnyaltabbá tenni ezeket a fogalmakat. Négy háttértár-típust fogunk vizsgálni. A megadott sebességértékek csak nagyon közelítôek. A merevlemezek adatátviteli (írási és olvasási) sebessége 400-1200 Kbyte/s. A CD-ROM-oké 75-150 Kbyte/s, a dupla és tripla sebességûeké kétszer, illetve háromszor ekkora (elvben). A floppyké 8-23 Kbyte/s. Streamerek: a DC kazettások adatátviteli sebessége úgy 15 Kbyte/s körül van, a DAT streamerek sokkal gyorsabbak, adatátviteli sebességük 170-180 Kbyte/s. A sebességnek azonban még három nagyon fontos jellemzôje van. Az egyik az elérhetôség. Ez alatt azt értem, hogy a merevlemezen, CD-ROM-on, szalagon lévô anyagok bármelyike szinte azonnal elérhetô (a gép többnyire elvégzi a keresést helyettünk), ám a floppykat sûrûn kell cserélgetni (mentéskor, visszatöltéskor), avagy keresgélni kell köztük, s ez a mi idônkbôl megy el. Amíg várunk, mikor kell majd floppyt cserélnünk, az is. A leglassabb streamer is gyorsabb ilyen szempontból a leggyorsabb floppymeghajtónál. A másik sebességi jellemzô (a használat sebességét jellemzi, nem mûszaki adat, nem mérhetô) a használat online avagy offline módja. Erre nincs jó magyar szó. Online: használat közbeni; vagyis a programok közvetlenül elérhetik a vinyó, CD-ROM teljes területét. A floppykét is (egyszerre egyét), de 1-2 Mbyte ma már nem kapacitás... A streamerek által kínált kapacitáshoz csak úgy férhetünk hozzá, hogy elindítunk egy olyan programot, ami képes streamert kezelni. E képességet nem szokták beépíteni a programokba, kivéve az erre a célra készített backup programokat. A streamerek tehát jellemzôen offline (külön figyelmet igénylô, közvetlenül nem használható) háttértárak. Az offline használat persze sokkal nehézkesebb, idôrabló, de a streamerek úgyis elég lassúak... Kivéve a DAT steamereket! Nosza, csináltak is ""vinyósító" programot hozzájuk, amelynek segítségével merevlemezként használhatók. Kapacitásuk, adatátviteli sebességük megfelelô, mi kell még? Rövid elérési idô! Egy szalagmeghajtó sosem lesz oly gyors, mint egy lemez. Még a floppykét sem fogja elérni a sebességük. Legalábbis az elérési idejük mindenképp hosszabb lesz. Ez a harmadik fontos sebességi jellemzô. Ez a jellemzô sem fogható meg könnyen, mert például a merevlemezeknél erôsen befolyásolja, az elméleti értéktôl hosszabbá/rövidebbé teszi a szoftveres vagy hardveres lemezcache jelenléte, s a lemez és a file-ok ""töredezettsége". A merevlemezeken többnyire gyorsan elérhetô bármelyik file, még a PC-s DOS-ok szerencsétlen FAT file-rendszere alatt is. A vinyók átlagos (elméleti!) elérési ideje 9-25 ms, ennek köszönhetô a gyors elérés. A floppyké 80-150 ms, észrevehetôen lassabbak tehát, nemcsak adatátviteli sebességük alapján. A CD-ROM-ok átlagos elérési ideje 150-350 ms, tehát ilyen szempontból még a floppyknál is lassabbak! Ennek a nagy sûrûségû optikai adatrögzítés az oka, miatta nagyon finom pozicionálásra van szükség a lemezkezelés során. A steamereknél (szalaghossztól függôen) úgy fél--egy perc körül lehet az átlagos elérési idô, de offline elérés esetén ez a jellemzô nem túl fontos. Terjedelmi okból nem is foglalkozunk tovább az elérési idôvel, csak a ""DAT-vinyókkal" kapcsolatban. A DAT streamerekhez adott ""vinyósító" program csak a kezelésüket könnyíti meg, amennyiben megszokott file-kezelô programjainkkal (Norton Commander stb.), online módon kezelhetjük a szalagon lévô anyagokat, tehát úgy írhatunk a szalagra és úgy olvashatunk onnan vissza, mintha a szalag lemez lenne. Még programot is lehet futtatni így, de... Bár mostani tesztünkhöz nem kaptunk ilyen programot, mégis erôsen kétlem, hogy jól használható(k). A legtöbb program adatokat is kezel, van konfigurációs file-ja stb. Ezeknek merevlemezen kell lenniük az elfogadható sebesség érdekében. A programindítás pedig mindenképpen csigalassú... És akkor még nem beszéltünk a szalagok élettartamáról. Szóval a ""szalagvinyó" olyan lehetôség, amit (szerintem) nem érdemes kihasználni. Mindent összevéve én két alkalmazási területen tartom használhatónak a streamereket: hosszú távú, megôrzési célú tárolásra (archiválásra), és felügyeletet nem igénylô vinyómentésre (backupolásra). Mentésre a mai vinyóméretek mellett @Kcsak@N a streamerek jöhetnek szóba. Archiválásra a floppyk is alkalmasak, de mérlegelni kell a költségeket is! A legolcsóbb floppyforrás e pillanatban 14,20 Ft/Mbyte (Interdiscount, 5|1/4 colos DD lemezek, bulk -- doboz nélküli -- ár: 12 Ft/db, áfával; 83 trackes, 10 szektoros formattálást véve alapul), a legolcsóbb streamerszalag-forrás 15,25 Ft/Mbyte költségû (Lion, Lion DC 2120-as kazetták, legalább 10 db vétele esetén 1450 Ft + áfa). Åm mind az archiválás, mind a mentés költségeinél figyelembe kell venni saját idônk értékét is -- így már @Ksokkal@N olcsóbb a streamerek használata. A meghajtók ára is erôsen befolyásolhatja döntéseinket. A költségek szemszögébôl tekintve a streamervétel beruházás, amelynek megtérülését jövôbeli idômegtakarításainktól várhatjuk. És a károknak a rendszeres mentések révén való elkerülésétôl. Számszerû elemzést cikkünk második részében tudunk adni errôl (folynak a mérések). @VMódszerek@N Archiválni szerintem offline módon tömörített anyagokat érdemes. Az álláspont vitatható (nem is követi mindenki ezt a gyakorlatot), ám védhetô: az offline tömörítôk (ARJ, PKZIP, LHA stb.) @Kcélprogramok@N, amelyeket tömörítésre találtak ki és alkottak meg. Tömörítés/idô hányadosként meghatározható hatékonyságuk ennek köszönhetôen magasabb a backup szoftverekbe épített tömörítô algoritmusokénál. Egyszerûbben mondva: ha a legkisebbre akarjuk csökkenteni a learchivált anyagok helyigényét, akkor offline tömörítôvel dolgozzunk! S ha lejjebb adunk tömörségi elvárásainkból, akkor egy adott tömörítést leggyorsabban úgyszintén offline tömörítôvel érhetünk el. Aki nem hiszi, mérjen utána... (Azért mi is utánamérünk.) Az offline tömörítés viszont aligha praktikus mentés esetén. Minek tömörítsünk mentés elôtt? A rendrakás viszont nem árt (legalábbis full backup elôtt -- lásd késôbb), mert így gyorsabb lesz a mentés, nem fog megakadni a backup program (túlságosan töredezett merevlemez esetén bizony kifuthat egyes mûveleti lépéseknél a várakozási idôbôl, s mentés közben felbukkanó lemezhiba esetén sem mindig elnézôek a backup programok!), s élvezhetjük a rendberakott vinyó minden elônyét (könnyebb file-visszaállítás véletlen törlés után, gyorsabb lemezmûveletek stb.). Például a Norton Utilities segítségével a rendberakás a következôképpen néz ki. 1. lépés: a vinyó átnézése, a felesleges file-ok, könyvtárak törlése. 2. lépés: @KNDD.EXE /q@N -- ez ellenôrzi a lemezt, a hibákat interaktívan javíthatjuk. 3. lépés (C: meghajtó esetén): @KSPEEDISK.EXE C: /U /V@N avagy @KSPEEDISK.EXE C: /FF /V@N @K/SN@N -- ezek persze csak általunk javasolt paraméterezések. 4. lépés: jöhet a backup program! Mentéskor viszont érdemes bekapcsolni az @Konline@N, tehát a backup programba beépített tömörítést. Legalábbis a 386SX processzorú gépektôl felfelé. Megfelelô beállítás mellett ugyanis idôt nyerünk, s mindenképpen megtakarítunk háttértár-kapacitást. XT-ken (bár nem tudtuk kimérni) mindenképpen megnyúlik a mentési idô tömörítés esetén. Gyors gépeken viszont akár helyre optimált tömörítést is kérhetünk mentéskor, elviselhetô mentési idôket kapunk (a pontos adatokat cikkünk követekezô részében tesszük közzé). Archiválásainkat és mentéseinket érdemes megtervezni. Ad-hoc módon végezve e tevékenységeket könnyû olyan hibát véteni, ami sok keserûséget, felesleges munkát okoz a késôbbiekben. Az archiválások szervezésére nincs szabály, nincsenek olyan jól kidolgozott, a programok által támogatott módszerek, amelyeket követve elôre kiszámítható eredményt kapunk. Merevlemezeim könyvtárszerkezetét az évek során már sokféleképp alakítottam. Az utolsó, s úgy tûnik, legjobban bevált módszer: alkalmazási területek szerint csoportosítom a programokat, és csak ezek a csoportok kapnak önálló könyvtárt a gyökérkönyvtárban. îgy például a C:\UTY könyvtár a segédprogramoké (utility). Az archiválások során is ezt a csoportosítást követem. Egy külön könyvtár (ennek fura neve van: C:\!BRA) alkönyvtáraiba (ilyen alkönyvtár például a C:\!BRA\UTY, ide kerül minden, archiválásra szánt segédprogram) rakom az offline tömörített file-csomagokat, s egy-egy alkönyvtárat egyben archiválok. Persze mindenki maga határozza meg, milyen módszereket követ archiválásainál, én csak tippet adtam, ám egy biztos: az archiválásokat érdemes megtervezni -- és ebben senki nem segít. Ismét csak saját példámat tudom felhozni: az idôszûkében, kapkodva végzett archiválással eltárolt anyagaimat csak kínkeservesen tudom elôvadászni a lemezdzsungelbôl (ha egyáltalán sikerül). A mentéseknek viszont jól kialakult módszerei vannak (errôl cikkünk második részében bôvebben is írunk), ezeket a backup programok támogatják is -- de nem mindegyik támogatja mindegyiket. Pár szót a szalagmeghajtók, szalagok megbízhatóságáról. A floppykkal kapcsolatban én azt tapasztaltam, hogy ha egy floppyra írt file a felíráskor hibátlan (megegyezik az eredeti példánnyal; az ellenôrzô kóddal -- CRC -- végzett ellenôrzés hibátlannak mutatja stb.), s a floppyt nem hurcolásszuk, akkor a legócskább lemezen lévô anyagokat is vissza lehet olvasni még évek múlva is! Åm sokan szereztek kínos tapasztalatokat az ""utazó" (villamos, busz, metró stb.) floppykkal, s a szerkesztôségünkben (irodai környezetben) az utóbbi években ""anyagcserére" használt (tehát asztalról asztalra, géprôl gépre járó) floppyk a gondos használat ellenére csak pár hónapig bírják, aztán meghibásodnak, tönkremennek! És itt sincs (észrevehetô) különbség a márkás és no-name floppyk közt. Erôs a gyanúm, hogy hasonló a helyzet a streamereknél is. A streamerszalagok a nagyobb adatsûrûség, vékonyabb hordozóréteg és mágnezeshetô réteg miatt még sebezhetôbbek. Fokozott gondossággal kell használni ôket. A szalagok gyártói tipikusan 5-45 Celsius hômérsékletet és 20-80%-os relatív páratartalmat adnak meg a használathoz, illetve 5-32 Celsiust és 40-60%-ot a tároláshoz, mint biztosítandó körülményeket. Ezek komolyan veendô értékek! És azt a figyelmeztetést is csak a vakmerôek hagyják figyelmen kívül, hogy a párakicsapódás mind a meghajtók író-olvasó fejét, mind a szalagokat károsíthatja! Párakicsapódást például télen, fûtött helyiségbe lépve a szemüvegeken lehet tapasztalni -- és sokszor nem elég egyszer megtörölni a szemüveget (én is szemüveges vagyok), hanem meg kell várni, míg felmelegszik. Gondoljunk erre, amikor például streamer-szalaggal közlekedünk télen... A gyártók ökölszabályként azt javasolják, várjunk 8--24 órát a szalagok használatával, ha a tárolási és használati körülmények eltérôek (""different"), avagy annyit, amennyi ideig hidegben volt a szalag. A lényeg: várjunk. Ameddig tart a türelmünk... És felírás, visszaolvasás elôtt tekercseljük át (retension) a szalagot, ha hosszabb ideig tároltuk, vagy sûrûn használjuk ugyanazt a szalagrészt. A streamer-használók talán túlzott óvatosságnak tartják ezeknek az elôírásoknak a betartását, de szerintem itt lehet keresni az adatvesztések egyik forrását. És a szalagok több meghajtó közti cseréjében. Visszautalnék szerkesztôségi floppyjaink sorsára: mindannyiunkat megdöbbentett, milyen gyorsan mennek tönkre a floppyk (és a floppymeghajtók!) rendszeres irodai használat mellett. Lepillantva a mellettem lévô gépben éppen mûködô Hewlett-Packard JetStore 5000 streamerre (2 Gbyte-os szalag van benne, DAT streamer), újabb tápot kap a ""DAT-vinyókkal" szembeni kételkedésem. A HP meghajtó úgy kezeli a parányi szalagkazettát, mint a videomagnók: behúzza a kazettát, befûzi a szalagot, a kidobógomb megnyomására kifûzi a szalagot, és finoman kicsúsztatja a kazettát -- de nem ez a lényeg, hanem az, hogy a kazetta behúzása után a meghajtó belsejét védô billenôlap bebillentve marad, szabadon hagyja a belsô mechanika egy részét! A floppymeghajtók (s közvetve a floppyk) halálát nálunk a porosodás okozta (okozza): a meghibásodott meghajtók belseje tele volt pormacskákkal (horror!), a gépek ventilátora ugyanis csinos kis huzatot kelt a floppymeghajtókon át... A HP JetStore-ral szalagvinyósító programot használva ugyanez várható, csak hamarabb, mivel egész nap nyitva lesz a floppymeghajtókénál jóval nagyobb nyílás (bár maga a meghajtó jóval zártabb), és a DAT szalagok roppant érzékenyek lehetnek az órási adatsûrûség miatt. Legközelebb a tesztre beérkezett streamerekkel szerzett tapasztalatainkat, a backup programokat, és mérési eredményeinket tekintjük át. @KBérces László@N ┌──────────────────────────────────────────────────────────┐ │ @VVészhelyzetben@N │▒ │ │▒ │ Mit lehet tenni, ha nem tudjuk visszaolvasni a szalagon │▒ │ lévô anyagot? Csak semmi pánik! │▒ │ │▒ │ Elôször is gondolkodjunk el azon, mit csinálhattunk │▒ │ rosszul (kiváló alkalom tanulni az elkövetett hibából). │▒ │ Például: betartottuk a szalaggyártók által elôírt │▒ │ környezeti követelményeket? Aztán: kértünk │▒ │ mentés/archiválás utáni összehasonlítást (compare) a │▒ │ backup programtól? Ennek során a program ugyanis │▒ │ összehasonlítja a file-ok merevlemezen lévô eredeti és │▒ │ a szalagon lévô elmentett állapotát. Ha eltérést │▒ │ tapasztal, vagy nem tud visszaolvasni egy szalagrészt, │▒ │ jelez -- vagyis mentéskor/archiváláskor derül ki a │▒ │ hiba, amikor még könnyû kijavítani. Végül: │▒ │ megpróbálhatjuk egy másik programmal visszaolvasni a │▒ │ szalag tartalmát. Elég meglepô, de a backup programok │▒ │ közt eltérést tapasztaltunk a szalagkezelés biztonságát │▒ │ tekintve (is). Meglepô, mert a streamerek (mûködésük │▒ │ megfigyelése alapján legalábbis úgy tûnik) fix │▒ │ parancskészlettel (ez persze streamerenként eltérô │▒ │ lehet) dolgoznak. Tény azonban, hogy a különben nagyon │▒ │ jó Central Point Backup (ez van a PC Toolsban is, és │▒ │ sok streamerhez is a CPB leegyszerûsített változatát │▒ │ adják) néha ""szem elôl veszti" a szalagot. Ha │▒ │ elérhetô egy másik backup program, próbálkozzunk meg │▒ │ vele, hátha azzal sikerül visszaolvasni a szalag │▒ │ tartalmát! Az utolsó lehetôség: a gép ki- és │▒ │ bekapcsolása, majd ismételt próbálkozás. Méréseink │▒ │ során ugyanis elôfordult, hogy egy szembetûnôen lassú │▒ │ mentés után ki- és bekapcsolva a gépet ""rendbejöttek a │▒ │ dolgok". │▒ └──────────────────────────────────────────────────────────┘▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ┌──────────────────────────────────────────────────────────┐ │ @VMentési sebességek@N │▒ │ │▒ │ A Tulip/Colorado Jumbo streamer felhasználói útmutatója │▒ │ közöl irányértékeket a különbözô sebességû gépeken │▒ │ végzett különbözô tömörítési beállítású mentések │▒ │ idôigényére vonatkozóan. A perc:másodperc formában │▒ │ megadott idôk 10 Mbyte mentésére, s természetesen csak │▒ │ a DC kazettával dolgozó Jumbóra és a hozzá adott backup │▒ │ programra vonatkoznak. A maximális tömörítést │▒ │ ""optimize for space", a gyorsat ""optimize for time" │▒ │ elnevezéssel szokták felkínálni a backup programok. Ez │▒ │ pontatlan, mivel meglehetôsen rugalmatlan │▒ │ algoritmusokkal dolgoznak, szó sincs idôre optimálásról │▒ │ (csak közelítôleg). 486-os gépeken például tipikusan │▒ │ gyorsabb (!) a maximális tömörítés az ""idôre │▒ │ optimáltnál". │▒ │ │▒ │ processzor tömörítés maximális gyors │▒ │ nélkül tömörítéssel tömörítéssel │▒ │ │▒ │ 386/33 MHz 5:29 3:09 2:58 │▒ │ │▒ │ 386/25 MHz 5:29 5:48 3:10 │▒ │ │▒ │ 386/16 MHz 5:29 8:03 4:32 │▒ │ │▒ │ 286/8 MHz 5:29 14:58 9:07 │▒ │ │▒ │ 8088/4,77 MHz 10:16 52:25 31:12 │▒ │ │▒ │ Mint látszik, a tömörítés nélküli mentések idôigénye az │▒ │ XT feletti gépeknél nem függ a gép sebességétôl. A │▒ │ tömörítést bekapcsolva nagyon megváltozik a kép, │▒ │ látszik, hogy minél gyorsabb a gép, annál inkább │▒ │ érdemes tömörítést, illetve maximális tömörítést kérni │▒ │ a backup programtól. Ez egyébként a DAT streamerekre │▒ │ is igaz lehet(ne), csak éppen ezek önmaguk is online │▒ │ tömörítést végeznek -- az áruk ésszerûvé tette e │▒ │ képesség beépítését. Ha mégis akarunk/kell a backup │▒ │ programmal tömöríteni, a DAT streamerek gyorsabb volta │▒ │ miatt arra számíthatunk, a gép sebessége még inkább │▒ │ beleszól a mentések idôtartamába. A lényeg: mérjük meg, │▒ │ hogy mennyi ideig tart a fenti három tömörítési │▒ │ beállítással egy teljes mentés (ez célszerûen három │▒ │ különbözô alkalommal történhet), s válasszunk a mért │▒ │ idôk és a mentések tapasztalt szalagigénye alapján. │▒ │ Ugyanis sem a fenti táblázat, sem az általunk mért idôk │▒ │ nem adják majd meg a konkrét gépen használt adott │▒ │ backup program sebességét a különbözô tömörítési │▒ │ módszerekkel. Túl sok tényezô befolyásolja ezt. │▒ └──────────────────────────────────────────────────────────┘▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ┌──────────────────────────────────────────────────────────┐ │ @VMentési szisztémák@N │▒ │ │▒ │ A mentések alaptípusai: teljes (full, total), teljes │▒ │ másolat (full copy, total copy), növekményes │▒ │ (incremental, modified), a növekmény másolata │▒ │ (incremental copy), különálló növekményes (separate │▒ │ incremental), különbségi (differential). Az elsô kettô │▒ │ minden file-t elment, a második pár egy teljes mentés │▒ │ folytatását jelenti, az utolsó kettô a második pár │▒ │ mentési sorozaton kívüli változata. A párok elsô tagja │▒ │ törli a file-ok archív attribútumát, a második nem. │▒ │ │▒ │ Nézzük részletesebben! A DOS a file-ok úgynevezett │▒ │ archív jelzôjét (attribútumát) arra a célra tartja │▒ │ fenn, hogy a backup programok nyilvántarthassák, mely │▒ │ file-okat mentettek már el. Teljes típusú mentéskor a │▒ │ backup programok minden file-t elmentenek, s törlik a │▒ │ file-ok archív attribútumát. Ha egy ilyen, törölt │▒ │ archív attribútumú file-t egy program módosít, akkor az │▒ │ archív bitet a DOS ismét ""bekapcsolja". Az archív │▒ │ attribútum tehát azt jelzi, hogy ""ezt a file-t még nem │▒ │ mentették el". Növekményes backupnál csak az archív │▒ │ attribútumú file-ok mentôdnek el. A megfelelô │▒ │ biztonsághoz így egy teljes backup után már elegendô │▒ │ csak növekményes backupokat készítenünk, ha megôrizzük │▒ │ az indító teljes backupot és az összes ezt követô │▒ │ növekményest. A full copy típusú mentés abban │▒ │ különbözik a fulltól, hogy itt a backup program nem │▒ │ törli a file-ok archív attribútumát. A full tehát az │▒ │ összes file-t, az incremental csak az archív │▒ │ attribútumú file-okat érintô, a full/incremental copy a │▒ │ másoló, vagyis az archív attribútumot nem törlô mentést │▒ │ jelent. A differential azonos az incremental copy │▒ │ mentéssel, csak éppen új szalagon/floppyn indul (a │▒ │ program nem fûzi hozzá az aktuális mentési sorozathoz). │▒ │ Separate incrementalt kérve új szalagon/floppyn induló │▒ │ incremental mentést kapunk. A különféle mentési │▒ │ szisztémák ezekbôl az alaptípusokból épülnek fel. │▒ │ │▒ │ A lényeg: eredményes backupolást csak valamilyen │▒ │ backupolási szisztémát követve lehet végezni. │▒ │ Legegyszerûbb esetben például minden napot úgy fejezünk │▒ │ be, hogy elindítunk egy full avagy full copy típusú │▒ │ mentést. Ez persze idôigényes, a többi mentési │▒ │ szisztéma ezt az idôt rövidíti le. Egy másik elterjedt │▒ │ módszer: hétfôn teljes, a hét többi napján növekményes │▒ │ mentés, majd hétfôn újrakezdés az elsô │▒ │ szalaggal/floppyval, felülírást kérve. Hosszabb távra │▒ │ gondoló, s így a vírusok ellen jobban védô szisztémák │▒ │ is vannak, ezek ismertetésétôl megkímélem az olvasókat │▒ │ (nem vagyok elvakult backup-hívô). │▒ └──────────────────────────────────────────────────────────┘▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒